原帖 ｜ Jason ｜ 2026-08-25 18:17 ｜ 👍0 ｜ 阅读约1
很多刚接触 Linux / Android 的同学，搞不懂 coredump 到底是什么。
以前做单片机 MCU 开发，Keil 搭配J‑Link，直接在线调试，可以单步执行、看变量，必现或者高概率复现的bug，基本都能搞定。这就是在线调试，调试器直接接板子，现场定位问题。
但到了量产设备就不一样了，机器都在用户手里，你根本拿不到板子，没法上J‑Link做在线调试。只能走离线调试这条路：尽可能在故障发生那一刻，把现场的日志、寄存器状态全部dump下来，打包压缩，再回传到后台。当然这里会涉及隐私方面的顾虑，但这也是嵌入式行业量产产品很常规的一套方案。
后台拿到的这一份故障压缩包，就是我们常说的 coredump，行业内部也叫 DB。
以我日常用的 Soc 来说，coredump 出来的内容很全：各个子系统的日志、故障时刻寄存器数值、片上 bus 总线状态、DDR 内存快照、各个 CPU core 现场、函数调用栈 backtrace，还有 thermal 温度、PMIC 电源状态等等，能抓的现场信息基本都会收集，你想到的会收集，你想不到的其实也会收集😉。压缩包一般好几个 GB，目的就是故障触发一次，就能把问题解决掉。
这个 DB 不是普通文件，必须用芯片厂商配套的专属解析工具才能还原出来。一般配套各模块的 symbol，asm，elf，map 去还原。
做量产产品，大家看的是 DPPM，百万台故障率。举个例子，问题 1/1000 复现概率，听着好像不高，换算 DPPM 就是 1000，对于量产来说已经完全不能接受。
所以，看懂、学会分析 coredump，是嵌入式高级工程师一定要会的（printk/ftrace/KASAN 等内核调试手段见 Linux 调试手段，涵盖 printk 使用、动态打印、trace）。
相关笔记
- 📁 返回本主题 MOC
- 从MCU转Linux BSP开发
- Linux BSP问题闭环流程
- Linux 调试手段，涵盖 printk 使用、动态打印、trace
- DDR替换后内核崩溃排查
- 嵌入式Linux调试iic
- Linux编译视角调试方法